1. Field of the Invention
The invention relates in general to a method and apparatus for native method invocation and changing memory bank, and more particularly to a method and apparatus capable of enhancing the memory usage by keeping a native method operating mechanism and changing between memory banks in a smart card.
2. Description of the Related Art
The usage of the smart card is getting more and more popularized with the wider and wider popularization of the actual applications of the modern cryptography, such as electronic commerce and electronic missive. A Java card belonging to the smart card is one of the actual applications and plays a relatively important role.
FIG. 1 is a system structure diagram showing a conventional Java card. As shown in FIG. 1, in addition to the hardware 100 in the bottom layer, the software system of the Java card may be divided into two parts including a Java card API (Application Programming Interface) 102 and a Java card system classes 104 constituted by Java codes, and a Java card virtual machine (JCVM) 106, a native method 108, and a Java card operating system 110 according to the native codes used by the microprocessor in the bottom layer hardware 100. In the actual application, a microprocessor with hardware encrypting function or a microprocessor together with a coprocessor with decrypting capability serves as a main portion of the bottom layer hardware 100, and an indispensable virtual machine such as the so-called JCVM 106 in the Java system is provided to complete the overall Java card system. No matter what kind of method is used, the limitation to the specification of Java Card Code is that the system can only address to 16 bits. That is, the programs relating to the Java Code, such as Java card API 102, Java card system classes 104, Java card application program (Applet, AP) 112, and the like, can occupy only 64K bytes in the memory owing to the limitation of the addressing capability of the Java card.
FIG. 2 is a flow chart showing conventional steps of a native method invocation of a Java card application program. First, in step 20, when the upper layer invocates the native method A (e.g., the Java card application program, the Java card API, or the Java card system classes invocates the native method A), the associated Java card native method interface (e.g., the interface of the native method A in the Java card system classes) is firstly invocated. Next, in step 22, when the virtual machine interpreter loop of the system has detected the invocation of the native method A, the system enters the recognition procedure of the native method to find the corresponding native codes of the native method A. Finally, in step 24, the system further transfers the program counter (PC) to the native method and executes the PC, and the invocation steps of the overall native method are thus completed. In general, the native code of the native method can be put outside the field of the visible 64K bytes of the Java card according to the processing capability of the microprocessor in the Java card.
At present, in the actual application of the Java card, some manufacturers have started to develop microprocessors, which are capable of supporting the complete Java card bytecodes, in conjunction with a coprocessor with decrypting capability to constitute a complete bottom layer hardware core. Thus, in the Java card having this technology, its associated software portion including the Java card virtual machine, the native method, and the like are constituted by the Java card bytecodes. However, because this system is restricted by the 16-bit addressing capability of the Java card, all the software system programs have to be put within the 64K bytes of the memory, which make the usable space of the system very small.